1. Field of the Invention
The present invention relates generally to a virtual connection manager that maintains virtual connections from outside machines to a local machine or group of machines. Specifically, the invention relates to a method for keeping track of the state of the virtual connections at a failover connection manager so that, if the active connection manager fails, the failover connection manager can become active and handle the connections without requiring the outside machines to break their connections and reestablish new connections.
2. Description of the Related Art
A Local Director connection manager that manages connections from remote clients to a local group of web servers is described in U.S. patent application Ser. No. 08/850,248, filed May 2, 1997, now U.S. Pat. No. 6,317,775 issued Nov. 13, 2001; U.S. patent application Ser. No. 08/850,730, filed May 2, 1997, now U.S. Pat. No. 6,061,349 issued May 9, 2000; U.S. patent application Ser. No. 08/850,836, filed May 2, 1997, now U.S. Pat. No. 6,104,717 issued Aug. 15, 2000; U.S. patent application No. 08/918,024, filed Aug. 25, 1997, now U.S. Pat. No. 6,108,300 issued Aug. 22, 2000; and U.S. patent application No. 08/920,211, filed Aug. 25, 1997, now U.S. Pat. No. 5,989,060 issued Nov. 23, 1999, which were previously incorporated by reference for all purposes.
The Local Director manages requests from remote clients to IP addresses corresponding to virtual machines implemented on the Local Director by translating the destination IP address and port number of incoming packets to the destination IP address and port number of a real machine that the Local Director has at its disposal to handle connections for the virtual machines that the Local Director is implementing. Likewise, the Local Director simulates responses from the virtual machines to the remote clients by translating the source IP address and port number of the real machines that the Local Director has at its disposal to the source IP address and port numbers of the virtual machines that the Local Director is implementing. Thus, the outside clients establish a connection that appears to be a connection to a virtual machine corresponding to destination IP address and destination port number selected by the client. The Local Director translates IP addresses and port numbers of inbound and outbound packets so that packets from the client are directed to a real machine that is selected by the Local Director to handle the virtual connection and packets from the real machine appear to the client to have originated from the virtual machine.
It should be noted that the terms client and server are used to refer to remote machines and local machines, respectively. In certain systems, the client and server designations may actually be reversed and it should be remembered that the following description could equally apply to local virtual clients and remote servers. Furthermore, although the invention will be specifically described as relating to the Local Director it should be appreciated that the method and apparatus described herein would be applicable to other connection managers that maintain information about the state of various virtual connections. Therefore, the terms Local Director and connection manager are used interchangeably throughout this specification.
Because the Local Director often functions as a single connection point or gateway to a group of servers that function as web servers that implement a large number of virtual servers having virtual IP addresses, the Local Director is potentially a single point of failure that could completely knock out all of the websites corresponding to virtual IP addresses served by the Local Director. Since this is undesirable, it is important that a standby or backup Local director be provided to handle connections when the primary or active Local Director fails. A method for detecting failure of a Local Director and activating a backup Local Director to handle connections is described in U.S. patent application Ser. No. 08/918,024, filed Aug. 25, 1997, now U.S. Pat. No. 6,108,300 issued Aug. 22, 2000 which was previously incorporated by reference. Two IP addresses, an active IP address and a failover IP address, are provided. When failure of the active Local Director is detected by a standby Local Director, then the standby Local Director assumes the active IP address and begins handling connections.
When the standby Local Director becomes active, it does not have all of the information about the connections that were being maintained by the failed Local Director. Therefore, packets corresponding to those connections cannot be handled by the newly active Local Director. The packets are dropped or error messages are sent to the packet senders. The connections handled by the failed Local Director then are torn down and new connections are established through the standby Local Director. Tearing down all of the connections handled by the failed Local Director and establishing new connections through the standby Local Director causes delay for the clients and introduces a significant amount of overhead on the newly activated standby Local Director while all of the former connections are being reestablished. Furthermore, each of the connections must be torn down by whichever physical machine (also referred to as a real machine) was selected to handle the connection by the failed Local Director at the same time as the new connections that are replacing the old connections are being established.
It would be useful if a method could be devised to have the standby Local Director replace the failed Local Director and also obtain the state of all the connections handled by the failed Local Director so that the connections would not need to be dropped and reestablished. What is needed, therefore, is a way of tracking the state of the connections made through an active Local Director at a standby Local Director and a method of causing the standby Local Director to activate and handle the connections when the primarily Local Director fails. Ideally, such a method should require a minimum amount of processing by the active Local Director and should take advantage of the unused processing power of the standby Local Director which itself does not need to handle connections while it is in stand by mode.